One or more of the following people are relevant to this code:

• @Qiskit/terra-core

The only question left is whether we should still have the panic condition in name_to_packed_operation because this check is done on a name basis rather than instance.

I'd like to bring this up again, in case it is a genuine concern. Since most of this fix might be superseded by #15684, we won't need to even go through Python in the future.

Where specifically is the panic? We shouldn't be panicking in general on the name unitary, that's something that will be used a lot. In general we shouldn't be panicking unless the underlying data structures are completely invalid (as in something corrupted them).

Where specifically is the panic? We shouldn't be panicking in general on the name unitary, that's something that will be used a lot.

I agree with this @mtreinish. I mistakenly added this in the past believing that there was no way we'd end up ever retrieving or querying a UnitaryGate or a gate named "unitary" from an equivalence library.

The panic happens specifically during the compose_transforms method where we would introduce a placeholder gate with the provided name into a dag. However, since we moved most of the infrastructure to rust, to remove ourselves from python, we would create rust native versions of gates. The original implementation included a variant for unitary but after further discussion we agreed that it wouldn't make sense for a unitary to end up there anyway, so I mistakenly made it into an unreachable!() call.

Ideally, it would be best to throw away this panic condition in favor of just going through Python instead since #15684 will modify this to perform all tasks from rust.